This disclosure relates to security provisioning.
The prevalence and accessibility of computer networks requires security measures to protect valuable information. An enterprise, for example, can implement such security measures by use of a layered security system. Such a layered security system can be implemented at the network edge of the enterprise, e.g., firewalls, gateway security agents, etc. Additionally, a layered security system can also include security processes and agents that are implemented throughout the enterprises, e.g., virus scanning software on each computer device within the enterprise, content filtering software, content monitoring software, etc.
However, such layered security systems are prone to processing inefficiencies and can require many resources within the enterprise to maintain the systems. The use of an “in-the-cloud” distributed security system that provides security services external to a network edge of an enterprise can overcome many of these processing inefficiencies. Examples of such distributes security systems and methods are disclosed in U.S. application Ser. No. 12/128,371, filed May 28, 2008 and entitled “Distributed Security Provisioning,” and U.S. application Ser. No. 12/179,441, filed Jul. 24, 2008 and entitled “HTTP Authentication and Authorization Management,” the disclosures of which are incorporated herein by reference.
In the distributed security systems described in the above-reference applications, an enterprise can transmit data to and receive data from the distributed security system by use of tunneling technologies. Example tunneling technologies include generic routing encapsulation (GRE), layer two tunneling protocol (L2TP), point-to-point tunneling protocol (PPTP) or IPSec protocols may be used. Virtual private network (VPN) routers and VPN concentrators can be used to achieve the traffic redirection for tunneling.
The use of tunneling, however, presents the enterprise with specific challenges and problems. One problem is that when a node for a tunnel fails, newly established tunnel end points after a tunnel is reestablished differ in their internet protocol (IP) addresses. Hence tunnel packets that are in the transit and addressed to the previous IP address are lost in the internet cloud, causing retransmission and disconnects of the client connections.
Another problem is that asymmetric routing paths can cause one tunnel end to infer the tunnel to be “dead” while the other tunnel end to infer the tunnel to be alive. When either end has discovered a path fault, a common good path must be provided to reach the tunnel ends. Existing tunneling protocols do not address this problem.
Yet another problem is that tunneling is agnostic to the type of traffic being carried in the tunnel. In security service provisioning, two types of traffic are originated. User's data traffic and user's authentication traffic. By using tunneling, both the data and authentication traffic are directed to the processing node, which in turn has to delegate the traffic to the authentication nodes.
Another challenge is the acceptance of user sessions at a different security service nodes during failover without traffic interruption or repeated user logins. Unless the authenticated state of the users of the tunnel is communicated to the distributed service nodes, a tunnel failure may create repeated user authentications.
Another challenge occurs when connections from a security service node may use a public IP address owned by the security service and not owned by the enterprise. Thus, location based services may be disrupted by the use of the service owned addresses.
Yet another challenge is present by the inability to perform seamless migration on a tunnel failure. Tunnel failures are detected by the health monitoring techniques of the underlying tunneling technology.